A network is a set of interconnected entities that can be dynamic in that it changes, evolves, adapts and decays over time. For example, new entities can be introduced, old entities can be removed, network topologies can change, links for interconnection can be down or replaced or enhanced, new versions of software can be activated, number of subscribers to network services grow, volume of network traffic fluctuates, etc.
In an example telecommunications network there are entities that serve as event reporters, event managers and event consumers. Event Reporters (ERs) are entities whose responsibilities are to detect the occurrences of network events and report them. Event Managers (EMs) are entities that collect the event reports from the ERs. An EM is part of the 3GPP defined Element Manager which provides a package of end-user functions for management of a set of closely related types of network elements. Event Consumers (ECs) are entities that retrieve and read event reports for up-to-date knowledge of the state or status of the managed network. FIG. 1 illustrates an example network topology, showing the relationship between ERs 54a-54n, an EM 52 and an EC 50 in terms of event reporting.
In a large network, there can be multiple realizations of each logical function. For example, multiple EMs, ECs and ERs can exist. One ER can send reports to multiple EMs and one EC can receive from multiple EMs for event reports. In addition, the number of ERs, EMs and ECs of a dynamic network can change over time. Furthermore, the number of ECs can be an order of magnitude more than that of EMs. The number of ERs is multiple orders of magnitude more than that of EMs.
In such a network, these logical functions can be implemented inside network nodes such as a Network Element (NE), a Domain Manager (DM) and a Network Management System (NMS) (also referred to as the Network Manager (NM)). A NE is a discrete telecommunications entity. Multiple logical ERs can be implemented inside a single physical NE. A DM provides element management functions and domain management functions for a sub-network. An EM can be implemented in a DM. An NMS provides a package of end-user functions with the responsibility for the management of a network, mainly as supported by the EM(s) but it may also involve direct access to the NEs. An NMS can include one or more ECs (for example, an NMS process that issues a command to retrieve currently active alarms is playing the role of an EC).
There are generally two categories of network events. One is serious in that it normally would require operator immediate attention. This category of event is reported by an Alarm report. The other is not serious in that it normally reports some normal network state or status changes. This category of event is reported by a Non-alarm report.
As defined by 3GPP TS 32.111-2 Fault Management, the contents of which are incorporated herein by reference, an Alarm report includes the following parameters: Target Entity Name, Event Type (such as “Processing Error Alarm”), Event Subtype, Probable Cause (such as “Broadcast Channel Failure”), and others.
As defined by 3GPP TS 32.662 Configuration Management, the contents of which are incorporated herein by reference, a Non-alarm report includes the following parameters: Target Entity Name, Event Type (such as “Object Creation”), and others.
The terminology “ER-kind” will be used in the present disclosure to denote an event reporter logical function that detects a specific “kind” or type of network event related to a specific entity and reports about it. For example, ER-kind1 can detect a network event “kind1” that would result in alarm reporting. Network event kind1 would correspond to a specific Event Type, a specific Event Subtype, a specific Probable Cause, and a specific target named entity. These are standard parameters in event reporting.
In another example, ER-kind73 can detect a network event kind73 that would result in non-alarm-type reporting and the network event would correspond to specific Event Type and specific target named entity characteristics.
When a network event of kind1 occurs, multiple ER-kind1 instances can detect it and report it. This conventional event reporting system results in multiple event reports, all carrying the same information, to be received and processed by the appropriate EMs and ECs. Such a large volume of duplicated event reports results in wasting communication bandwidth between an EM and ERs, wasting communication bandwidth between an EM and ECs, and wasting EM or EC processing times/cycles to filter, correlate and discard the redundant event information.
FIG. 2 illustrates a conventional event/alarm information flow topology for a large telecommunication network. NEs 64a-64g can include the functions of many ERs. The DM 62 performs the role of the EM. It collects alarms from multiple NEs 64a-64g via Interface-A 66. The NMS 60 performs the role of an EC. It collects alarms from the DM 62 via Interface-B 68. Note that there is only one exemplary NMS 60 shown in FIG. 2, but there could be multiple NMSs all receiving alarms from DM 62. In real telecommunication network, there could be thousands of such NEs reporting alarms to one DM. An international standard reference model for the NMS, DM, NE and their interfaces are described in 3GPP TS 32.101 Telecommunication management; Principles and high level requirements, the contents of which are incorporated herein by reference.
In the conventional network of FIG. 2, if X number of alarms are generated by the ERs of NEs 64a-64g, X number of alarms—regardless if they carry identical network fault occurrence—will be reported to the EM of DM 62. The NMS 60, supported by DM 62, will also receive X number of alarms.
Therefore, it would be desirable to provide a system and method that obviate or mitigate the above described problems.